Performance mode #1014
Performance mode #1014
Conversation
Can you please share a reference on this? For my understanding ... Thanks! |
|
|
For the records, the PR is mostly based on the following doc page https://juliapackaging.github.io/Preferences.jl/stable/#API |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1014 +/- ##
==========================================
- Coverage 88.17% 88.16% -0.01%
==========================================
Files 178 179 +1
Lines 22562 22569 +7
==========================================
+ Hits 19895 19899 +4
- Misses 2667 2670 +3 ☔ View full report in Codecov by Sentry. |
|
I like the switch based on Preferences.jl, which provably makes sense even beyond the issue with But this is only a solution to part of the problem unfortunately. In Gridap (and multitude of Julia packages) there are a lot of loops without Do you have any idea/opinion on how to proceed regarding array indexing if julia removes |
Following Tim Besard's comments on that issue, I believe the GPU people have just gone ahead and created their own compiler (which we obviously cannot do...). Another thing coming with Julia 1.11 is the new
I believe the problem is that even if it does not get deprecated, it is currently worse to disable bounds checking than to just have it... |
Hi everyone!
For some context:
The Julia flag
--check-bounds=nois, as far as I understand, currently unusable due to it causing type instabilities within the compiler. Within Gridap, we use this option to enable/disable the@checkmacro. This means we do not currently have an option to deactivate such checks. Some heavy calculations are hidden behind those checks, so it would be nice to have the option to deactivate them.Moreover, there are currently packages that statically (at compile time) address this issue. In particular, the
Preferences.jlpackage offers an unified approach to deal with this. Very prominent Julia packages have been moving towards this approach, for instanceMPI.jlthroughMPIPreferences.jl.Given these two last points, I propose the following PR. It introduces a constant variable
execution_modethat can be set to eitherdebug(default) orperformance. The latter deactivates the@checkmacro at compile time.As a side note, I think we should also move towards this approach within
GridapPETSc.jlandGridapP4est.jl, instead of depending on environment variables (again, the approach taken byMPI.jl).I would appreciate some feedback on the issue, to make sure we are all on the same page.
Thanks!